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Abstract 
This document describes the use of the Advanced Encryption Standard 
(AES) Cipher Algorithm in Cipher Block Chaining (CBC) Mode, with an 
explicit Initialization Vector (IV), as a confidentiality mechanism 


within the context of the IPsec Encapsulating Security Payload (ESP). 
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1. Introduction 


As the culmination of a four-year competitive process, NIST (the 
National Institute of Standards and Technology) has selected the AES 
(Advanced Encryption Standard), the successor to the venerable DES 
(Data Encryption Standard). The competition was an open one, with 
public participation and comment solicited at each step of the 
process. The AES [AES], formerly known as Rijndael, was chosen from 
a field of five finalists. 


The AES selection was made on the basis of several characteristics: 
+ security 
+ unclassified 
+ publicly disclosed 
+ available royalty-free, worldwide 
+ capable of handling a block size of at least 128 bits 


+ at a minimum, capable of handling key sizes of 128, 192, and 
256 bits 


+ computational efficiency and memory requirements on a variety 
of software and hardware, including smart cards 


+ flexibility, simplicity and ease of implementation 


The AES will be the government’s designated encryption cipher. The 
expectation is that the AES will suffice to protect sensitive 
(unclassified) government information until at least the next 
century. It is also expected to be widely adopted by businesses and 
financial institutions. 
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It is the intention of the IETF IPsec Working Group that AES will 
eventually be adopted as the default IPsec ESP cipher and will obtain 
the status of MUST be included in compliant IPsec implementations. 


The remainder of this document specifies the use of the AES within 
the context of IPsec ESP. For further information on how the various 
pieces of ESP fit together to provide security services, refer to 
[ARCH], [ESP], and [ROAD]. 


1.1. Specification of Requirements 


The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that 
appear in this document are to be interpreted as described in 
[RFC-2119]. 


2. The AES Cipher Algorithm 


All symmetric block cipher algorithms share common characteristics 
and variables, including mode, key size, weak keys, block size, and 
rounds. The following sections contain descriptions of the relevant 
characteristics of the AES cipher. 


2.1. Mode 


NIST has defined 5 modes of operation for AES and other FIPS-approved 
ciphers [MODES]: CBC (Cipher Block Chaining), ECB (Electronic 
CodeBook), CFB (Cipher FeedBack), OFB (Output FeedBack) and CTR 
(Counter). The CBC mode is well-defined and well-understood for 
symmetric ciphers, and is currently required for all other ESP 
ciphers. This document specifies the use of the AES cipher in CBC 
mode within ESP. This mode requires an Initialization Vector (IV) 
that is the same size as the block size. Use of a randomly generated 
IV prevents generation of identical ciphertext from packets which 
have identical data that spans the first block of the cipher 
algorithm’s block size. 


The IV is XOR’d with the first plaintext block before it is 
encrypted. Then for successive blocks, the previous ciphertext block 
is XOR’d with the current plaintext, before it is encrypted. 


More information on CBC mode can be obtained in [MODES, CRYPTO-S]. 
For the use of CBC mode in ESP with 64-bit ciphers, see [CBC]. 
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2.2. Key Size and Number of Rounds 


AES supports three key sizes: 128 bits, 192 bits, and 256 bits. The 
default key size is 128 bits, and all implementations MUST support 
this key size. Implementations MAY also support key sizes of 192 
bits and 256 bits. 


AES uses a different number of rounds for each of the defined key 
sizes. When a 128-bit key is used, implementations MUST use 10 
rounds. When a 192-bit key is used, implementations MUST use 12 
rounds. When a 256-bit key is used, implementations MUST use 14 
rounds. 


2.3. Weak Keys 


At the time of writing this document there are no known weak keys for 
the AES. 


Some cipher algorithms have weak keys or keys that MUST not be used 
due to their interaction with some aspect of the cipher’s definition. 
If weak keys are discovered for the AES, then weak keys SHOULD be 
checked for and discarded when using manual key management. When 
using dynamic key management, such as [IKE], weak key checks SHOULD 
NOT be performed as they are seen as an unnecessary added code 
complexity that could weaken the intended security [EVALUATION]. 


2.4. Block Size and Padding 
The AES uses a block size of sixteen octets (128 bits). 


Padding is required by the AES to maintain a 16-octet (128-bit) 
blocksize. Padding MUST be added, as specified in [ESP], such that 
the data to be encrypted (which includes the ESP Pad Length and Next 
Header fields) has a length that is a multiple of 16 octets. 


Because of the algorithm specific padding requirement, no additional 
padding is required to ensure that the ciphertext terminates on a 4- 
octet boundary (i.e., maintaining a 16-octet blocksize guarantees 
that the ESP Pad Length and Next Header fields will be right aligned 
within a 4-octet word). Additional padding MAY be included, as 
specified in [ESP], as long as the 16-octet blocksize is maintained. 


2.5. Additional Information 


AES was invented by Joan Daemen from Banksys/PWI and Vincent Rijmen 
from ESAT-COSIC, both in Belgium, and is available world-wide ona 
royalty-free basis. It is not covered by any patents, and the 
Rijndael homepage contains the following statement: "Rijndael is 
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available for free. You can use it for whatever purposes you want, 
irrespective of whether it is accepted as AES or not." AES’s 
description can be found in [AES]. The Rijndael homepage is: 
http://www.esat.kuleuven.ac.be/~rijmen/rijndael/. 


The AES homepage, http://www.nist.gov/aes, contains a wealth of 
information about the AES, including a definitive description of the 
AES algorithm, performance statistics, test vectors and intellectual 
property information. This site also contains information on how to 
obtain an AES reference implementation from NIST. 


2.6. Performance 
For a comparison table of the estimated speeds of AES and other 
cipher algorithms, please see [PERF-1], [PERF-2], [PERF-3], or 
[PERF-4]. The AES homepage has pointers to other analyses. 

3. ESP Payload 
The ESP payload is made up of the IV followed by raw cipher-text. 


Thus the payload field, as defined in [ESP], is broken down according 
to the following diagram: 


+--------------- +--------------- 4+--------------- +--------------- + 
+ Initialization Vector (16 octets) + 
+--------------- +--------------- +--------------- +--------------- + 


Encrypted Payload (variable length, a multiple of 16 octets) 


The IV field MUST be the same size as the block size of the cipher 
algorithm being used. The IV MUST be chosen at random, and MUST be 
unpredictable. 


Including the IV in each datagram ensures that decryption of each 
received datagram can be performed, even when some datagrams are 
dropped, or datagrams are re-ordered in transit. 


To avoid CBC encryption of very similar plaintext blocks in different 
packets, implementations MUST NOT use a counter or other low-Hamming 
distance source for IVs. 
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3.1. ESP Algorithmic Interactions 


Currently, there are no known issues regarding interactions between 
the AES and other aspects of ESP, such as use of certain 
authentication schemes. 


3.2. Keying Material 


The minimum number of bits sent from the key exchange protocol to the 
ESP algorithm must be greater than or equal to the key size. 


The cipher’s encryption and decryption key is taken from the first 
<x> bits of the keying material, where <x> represents the required 
key size. 


4. Test Vectors 


The first 4 test cases test AES-CBC encryption. Each test case 
includes the key, the plaintext, and the resulting ciphertext. The 
values of keys and data are either hexadecimal numbers (prefixed by 
"Ox") or ASCII character strings (surrounded by double quotes). Ifa 
value is an ASCII character string, then the AES-CBC computation for 
the corresponding test case DOES NOT include the trailing null 
character (’\0’) of the string. The computed cyphertext values are 
all hexadecimal numbers. 


The last 4 test cases illustrate sample ESP packets using AES-CBC for 
encryption. All data are hexadecimal numbers (not prefixed by "0x"). 


These test cases were verified using 2 independent implementations: 
the NIST AES-CBC reference implementation and an implementation 
provided by the authors of the Rijndael algorithm 
(http://csrc.nist.gov/encryption/aes/rijndael/ 
rijndael-unix-refc.tar). 


Case #1: Encrypting 16 bytes (1 block) using AES-CBC with 128-bit key 


Key : 0x06a9214036b8a15b512e03d534120006 
IV : Ox3dafba429d9eb430b422da802c9fac41 
Plaintext : "Single block msg" 


Ciphertext: 0xe353779c1079aeb82708942dbe77181a 


Case #2: Encrypting 32 bytes (2 blocks) using AES-CBC with 128-bit key 

Key : 0xc286696d887c9aa0611lbbb3e2025a45a 

IV : 0x562e17996d093d28ddb3ba695a2e6f58 

Plaintext : 0x000102030405060708090a0b0c0d0e0f 
101112131415161718191lalblcldlelf 

Ciphertext: Oxd296cd94c2cccf8a3a863028b5eldc0a 
7586602d253cfff9I1b8266beabd6labl 
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Case #3: Encrypting 48 bytes (3 blocks) using AES-CBC with 128-bit key 


Key : O0x6c3ea0477630ce21a2ce334aa746c2cd 
IV : Oxc782dc4c098cb66cbhd9cd27d825682c81 
Plaintext : "This is a 48-byte message (exactly 3 AES blocks)" 


Ciphertext: 0xd0a02b3836451753d493665d33f0e886 
2dea54cdb2 93abc7506939276772£8d5 
021¢19216bad525c8579695d83ba2684 


Case #4: Encrypting 64 bytes (4 blocks) using AES-CBC with 128-bit key 


Key : 0x56e47a38c5598974bc46903dba290349 
IV : Ox8ce82eefbeaNda3c44699ed7db51b7d9 
Plaintext : OxaQala2a3a4a5a6a7a8a9aaabacadaeaf 


b0b1b2b3b4b5b6b7b8b 9babbbchdbebf 
cOclc2c3c4c5céc7c8c9cacbcccdcecf 
d0d1d2d3d4d5d6d7d8d9dadbdcdddedf 
Ciphertext: Oxc30e32ffedc0774eb6aff6af0869f71laa 
Of3af07a9a31a9c684db207eb0ef8e4e 
35907aa632c3ffdf868bb7b29d3d46ad 
83ce9f9a102ee99d49a53e87f4c3da55 


Case #5: Sample transport-mode ESP packet (ping 192.168.123.100) 
Key: 90d382b4 10eeba7a qd938c46c ecla82bf 

SPI: 4321 

Source address: 192.168.123.3 

Destination address: 192.168.123.100 

Sequence number: 1 

IV: e96e8c08 ab465763 £d098d45 dd3ff893 


Original packet: 

IP header (20 bytes): 45000054 08f20000 4001f9fe c0a87b03 c0a87b64 

Data (64 bytes): 

08000ebd a70a0000 8e9c083d Þ95b0700 08090a0b Oc0d0e0f 10111213 14151617 
1819lalb 1c1idle1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 


Augment data with: 

Padding: 01020304 05060708 090a0b0c 0d0e 
Pad length: 0e 

Next header: 01 (ICMP) 


Pre-encryption Data with padding, pad length and next header (80 bytes): 
08000ebd a70a0000 8e9c083d b95b0700 08090a0b OcOd0eOf 10111213 14151617 
18191alb 1c1idle1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 
01020304 05060708 090a0b0c 0d0e0e01 
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Post-encryption packet with SPI, Sequence number, IV: 

IP header: 4500007c O08f20000 4032f9a5 c0a87b03 c0a87b64 

SPI/Seq #: 00004321 00000001 

IV: e96e8c08 ab465763 £d098d45 dd3ff893 

Encrypted Data (80 bytes): 

£663c25d 325c18c6 a9453e19 4e€120849 a4870b66 cc6b9965 330013b4 898dc856 
a4699e52 3a55db08 O0b59ec3a 8e4b7e52 775b07d1 db34ed9c 538ab50c 551b874a 
a269add0 47ad2d59 13acl19b7 cfbad4a6 


Case #6: Sample transport-mode ESP packet 
(ping -p 77 -s 20 192.168.123.100) 

Key: 90d382b4 10eeba7a d938c46c ecla82bf 

SPI: 4321 

Source address: 192.168.123.3 

Destination address: 192.168.123.100 

Sequence number: 8 

IV: 69d08df7 d203329d b093fc49 24e5bd80 


Original packet: 

IP header (20 bytes): 45000030 O08fe0000 4001fa1l6 cO0a87b03 c0a87b64 
Data (28 bytes): 

0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777 


Augment data with: 
Padding: 0102 

Pad length: 02 

Next header: 01 (ICMP) 


Pre-encryption Data with padding, pad length and next header (32 bytes): 
0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777 01020201 


Post-encryption packet with SPI, Sequence number, IV: 

IP header: 4500004c O08fe0000 4032f9c9 c0a87b03 c0a87b64 

SPI/Seq #: 00004321 00000008 

IV: 69d08d£f7 d203329d b093fc49 24e5bd80 

Encrypted Data (32 bytes): 

£5199588 lec4e0c4 488987ce 742€8109 689bb379 d2d750c0 d915dca3 46a89f75 


Case #7: Sample tunnel-mode ESP packet (ping 192.168.123.200) 
Key: 01234567 89abcdef 01234567 89abcdef 

SPI: 8765 

Source address: 192.168.123.3 

Destination address: 192.168.123.200 

Sequence number: 2 

IV: £4e€76524 4f6407ad £13dc138 0f673f37 
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Original packet: 

IP header (20 bytes): 45000054 09040000 4001f988 c0a87b03 c0a87bc8 

Data (64 bytes): 

08009f76 a90a0100 b49c083d 02a20400 08090a0b OcOd0eOf 10111213 14151617 
1819lalb lcldlelf 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 


Augment data with: 

Padding: 01020304 05060708 090a 
Pad length: 0a 

Next header: 04 (IP-in-IP) 


Pre-encryption Data with original IP header, padding, pad length and 
next header (96 bytes): 

45000054 09040000 4001f988 c0a87b03 cOa87bc8 08009f76 a90a0100 b49c083d 

02a20400 08090a0b OcOd0eOf 10111213 14151617 18191lalb Icldlelf 20212223 

24252627 28292a2b 2c2d2e2f 30313233 34353637 01020304 05060708 090a0a04 


Post-encryption packet with SPI, Sequence number, IV: 

IP header: 4500008c 09050000 4032£91le c0a87b03 c0a87bc8 

SPI/Seq #: 00008765 00000002 

IV: £4e76524 4f6407ad £13dc138 Of673£37 

Encrypted Data (96 bytes): 

77305241 a4c44922 5e4f3ce5 ed611lb0c 237ca96c £74a9301 3clb0eal a0cf70f8 
e4ecaec7 8ac53aad 7a0f022b 859243c6 47752e94 a859352b 8a4d4d2d ecd136e5 
c177£132 ad3fbfb2 201ac990 4c74ee0a 109e0cal e4dfe9d5 al00b842 flc22f0d 


Case #8: Sample tunnel-mode ESP packet 
(ping -p ff -s 40 192.168.123.200) 

Key: 01234567 89abcdef 01234567 89abcdef 

SPI: 8765 

Source address: 192.168.123.3 

Destination address: 192.168.123.200 

Sequence number: 5 

IV: 85047224 b5f3dd5d 2101d4ea 8dffab22 


Original packet: 

IP header (20 bytes): 45000044 090c0000 4001f£990 c0a87b03 cOa87bc8 

Data (48 bytes): 

0800d63c aa0a0200 c69c083d a3de0300 ffffffff fFLffffff fLffffff ffffffff 
ffffffff fFLfffff frffrffrff frrffrffft 


Augment data with: 

Padding: 01020304 05060708 090a 
Pad length: 0a 

Next header: 04 (IP-in-IP) 
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Pre-encryption Data with original IP header, padding, pad length and 
next header (80 bytes): 

45000044 090c0000 4001f£990 c0a87b03 cOa87bc8 0800dE3c aa0a0200 c69c083d 

asde0300: “fLEFELLE FEFEFE: -FEEFEE fFEEEPEES-PEPEPEC CE. FEPPELee. FEPEELE£L 

ffffffff 01020304 05060708 090a0a04 


Post-encryption packet with SPI, Sequence number, IV: 

IP header: 4500007c 090d0000 4032f£926 c0Oa87b03 c0a87bc8 

SPI/Seq #: 00008765 00000005 

IV: 85047224 b5f3dd5d 2101d4ea 8dffab22 

Encrypted Data (80 bytes): 

15b92683 819596a8 047232cc 00f7048f e45318e1 1f8a0f62 ede3c3fc 61203bb5 
O0f980a08 c9843fd3 alb06d5c 07ff9639 b7eb7dfb 3512e5de 435e7207 ed971lef3 
d2726d9b 5ef6affc 6d1l7a0de chb13892 


5. IKE Interactions 
5.1. Phase 1 Identifier 


For Phase 1 negotiations, IANA has assigned an Encryption Algorithm 
ID of 7 for AES-CBC. 


5.2. Phase 2 Identifier 


For Phase 2 negotiations, IANA has assigned an ESP Transform 
Identifier of 12 for ESP_AES. 


5.3. Key Length Attribute 


Since the AES allows variable key lengths, the Key Length attribute 
MUST be specified in both a Phase 1 exchange [IKE] and a Phase 2 
exchange [DOI]. 


5.4. Hash Algorithm Considerations 


A companion competition, to select the successor to SHA-1, the 
widely-used hash algorithm, recently concluded. The resulting 
hashes, called SHA-256, SHA-384 and SHA-512 [SHA2-1, SHA2-2] are 
capable of producing output of three different lengths (256, 384 and 
512 bits), sufficient for the generation (within IKE) and 
authentication (within ESP) of the three AES key sizes (128, 192 and 
256 bits). 


However, HMAC-SHA-1 [HMAC-SHA] and HMAC-MD5 [HMAC-MD5] are currently 
considered of sufficient strength to serve both as IKE generators of 
128-bit AES keys and as ESP authenticators for AES encryption using 
128-bit keys. 
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6. 


Security Considerations 


Implementations are encouraged to use the largest key sizes they can 
when taking into account performance considerations for their 
particular hardware and software configuration. Note that encryption 
necessarily impacts both sides of a secure channel, so such 
consideration must take into account not only the client side, but 
the server as well. However, a key size of 128 bits is considered 
secure for the foreseeable future. 


For more information regarding the necessary use of random IV values, 
see [CRYPTO-B]. 


For further security considerations, the reader is encouraged to read 
[AES]. 


IANA Considerations 


IANA has assigned Encryption Algorithm ID 7 to AES-CBC. 
IANA has assigned ESP Transform Identifier 12 to ESP_AES. 


Intellectual Property Rights Statement 


The IETF takes no position regarding the validity or scope of any 
intellectual property or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; neither does it represent that it 


has made any effort to identify any such rights. Information on the 
IETF’s procedures with respect to rights in standards-track and 
standards-related documentation can be found in BCP-11. Copies of 


claims of rights made available for publication and any assurances of 
licenses to be made available, or the result of an attempt made to 
obtain a general license or permission for the use of such 
proprietary rights by implementers or users of this specification can 
be obtained from the IETF Secretariat. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights which may cover technology that may be required to practice 
this standard. Please address the information to the IETF Executive 
Director. 
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